kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19990725-20000114/[e-mail] _Thu Aug 19 17:18:23 1999.msg

Internet Message Format | 2000-01-13 | 6KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA23496
    for <[e-mail]>; Thu, 19 Aug 1999 17:18:23 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA26982
    for [e-mail]; Thu, 19 Aug 1999 16:55:03 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Frank da Cruz)
Subject: Re: beta 6 Problem w/batch queue & USR-->USR Modem issue
Date: 19 Aug 1999 20:55:01 GMT
Organization: Columbia University
Message-ID: <7phqv5$qa3$[e-mail]>
To: [e-mail]

In article <7phlm8$nj0$[e-mail]>,
Michael Hamelin <[e-mail]> wrote:
> 1.) submiting a batch job into the vms queue, the displayed file
> information..text version of the file transfer doesn't work. get can't open
> tt: device
> Beta 8 gives us...
> %ckermit-w-notterm tt: is not a terminal
> sorry can't open connecion tt::  error 0
> ???
>
That sounds like you're telling it to transfer a file on its controlling
terminal, which is, in fact, the batch stream.  If you're running Kermit in
the batch, file-transfer commands won't work unless you've successfully
opened some kind of connection (SET LINE, DIAL, TELNET, etc).  This, in
turn, suggests that a SET LINE or DIAL command that's in your script did
not succeed.

> Downloaded beta 9 for vms-55 (nonet) and got an error on image activivation
> ???
>
The system where I built it was a bit strange.  By the time you get this
message, I will have put a replacement there that you can try.  Meanwhile,
are you sure you transferred it in binary mode?

> we are running batch jobs from fully priv account...not any issue under
> version 5. 5 runs excellant as detailed...
>
Version 5 of C-Kermit?

> this failed in beta 195..not sure
> if corrected yet. What we are saying here is that the computer spits out
> TT: not an output device, where as version 5 works fine and you get to see
> the file being transfered (serial transfer display). This is not the case
> in BETA 195. NO DISPLAY is possible running from the batch queue. The same
> username, script and command procedure run from version 5 and beta 195,
> this is the issue we are now facing. Only change is the ckermit
> version....Saw a not about this is the release notes, not sure what it
> meant. Just giving you pre-post results..
>
Which note are you speaking of?

> 2.) USR to USR still will not make a connect in ckermit. Ckermit is still
> getting the data and starting the login process, instead of just making the
> connect. We have solved it temp. by using a zoom modem as the dialer and
> the usr sportsters 33.6k modems in the field (34 stores). ckermit makes a
> connect and then the scripts appear to be fine after that.
>
> (frank's comments)
> >I don't understand the complaint.  What, precisely, do you mean by
> >"connect"?  You say "Ckermit is still getting the data and starting the
> >login process, instead of just making the connect."  You don't want it to
> >get the data and start the login process?  I can't help but suspect that it
> >is only doing what your script is telling it to do...
>
> (us)
> we sent you the scripts before...will send again if needed...we found a bug
> in the handshaking of the login scripts for vmslogin. new stuff was added,
> but the computer appears not to like it, so we used the logic from version
> 5 and it corrected the problem on login. The issue is still the same with
> USR to USR. If we use the USR in the stores and the ZOOM , HAYES, Anything
> but USR, CKERMIT does it thing correctly.
>
We get a lot of mail every day so it's best to give us the whole context.
Exactly what did the computer not like, and what did it like?

> The USR Will connect ..handshake and start the login process on the vax
> (waking the port up), the zoom and others only handshake and wait.
>
Maybe this will help.  Before version 6.0 of C-Kermit, DIAL and CONNECT were
done separately.  If you gave a DIAL command, you still had to give a CONNECT
command if you wanted to get an interactive online session.  But this was
too confusing for many people, so version 6.0 was changed so that DIAL
included an automatic CONNECT, but ONLY IF the DIAL command was given at
the prompt (interactively), not from a macro or a command file,

That's the DEFAULT behavior in C-Kermit 6.0 and later.  It can be changed
with:

  SET DIAL CONNECT { ON, OFF, AUTO }

AUTO is the default and works as I just described.  OFF means "never CONNECT"
automatically after successful dialing (the C-Kermit version 5 behavior), ON
means "always CONNECT".

Could it be that you have added a SET DIAL CONNECT of some form into your
script?

> The modem settings on the USR are identical to the ZOOM and IDentical to
> the remote modem. A Manual dial with USR to USR, will never get a connect
> message...
>
So a USR-to-USR call is never completed, but a USR-to-anything-else call is
completed.  I have several USR modems here, including one connected to a VMS
system, and I dial out from them to other USR modems all the time.  What's
the difference?  As you know, USR modems have a series of DIP switches for
configuration.  Maybe yours need adjustment.  Maybe some kind of weird
profile has been set up and saved in NVRAM.

- Frank